home *** CD-ROM | disk | FTP | other *** search
/ Amiga Aktuell / Amiga Aktuell.iso / amiga-aktuell / net tools / fido net / ftsc-all-91 / fsc-0058.z02 / fsc-0058.002
Text File  |  1992-11-01  |  20KB  |  393 lines
  1. Document: FSC-0058
  2. Version:  002 
  3. Date:     01-Nov-1992
  4.  
  5.  
  6.  
  7.                    A New Way Of Addressing In FidoNet(r)
  8.  
  9.                        Wim Van Sebroeck & Jan Spooren
  10.                              November 1st, 1992
  11.  
  12.             This document replaces the now obsolete version 001
  13.  
  14.  
  15.  
  16.     Status of this document:
  17.  
  18.      This FSC suggests a proposed protocol for the FidoNet(r) community,
  19.      and requests discussion and suggestions for improvements.
  20.      Distribution of this document is unlimited.
  21.  
  22.      Fido and FidoNet are registered trademarks of Tom Jennings and Fido
  23.      Software.
  24.  
  25.  
  26.  
  27. A. Why a new Proposal :
  28. ------------------------
  29. FidoNet has grown from a few single BBSs to a worldwide network of nodes.
  30. Because of that enormous growth, we have several kludge-lines just to write
  31. to someone else. And for every extra dimension a new kludge is necessary.
  32. (3D: ^AINTL ; 4D: ^AFMPT, ^ATOPT ; 5D: ^ADOMAIN). Every time a new
  33. dimension or addressing-system is invented, not only the packer/router
  34. software needs to be adjusted, but also the message editor and a whole
  35. series of other utilities, being virtually the whole FidoNet software.
  36.  
  37. This is why we made this proposal:
  38. 1) to make life easier for programmers and developers.
  39. 2) to have a system that will have no problems with further
  40.    backward-compatibility. (from this system on)
  41. 3) to have a system that is simple (in usage).
  42. 4) and to have a system that accepts every possible address.
  43.  
  44.  
  45. B. Proposal :
  46. --------------
  47. To send a message one needs two things: the origin address and the
  48. destination address. (And for routing inter-domain messages you also need
  49. the address of the gateway). Until now, we needed four different
  50. kludge-lines when we wanted to send a message to another domain (^ADOMAIN,
  51. ^AINTL, ^AFMPT, ^ATOPT). To minimize these kludges we suggest the
  52. following:
  53.  
  54.         ^ADEST <dest_address>
  55.         ^AORIG <orig_address>
  56.         ^AROUTE <route_via_address>
  57.  
  58. These kludges are *not* followed by a colon (':').
  59.  
  60. 1) The ^ADEST kludge: this kludge contains the address where the message
  61.    has to be sent to. In other words: it contains the destination address.
  62.    <dest_address> is an ASCII string that may contain any readable
  63.    character, (above and including 32 (space) and below ASCII 128), and is
  64.    only terminated by the end-CR of the kludge-line. It is up to the
  65.    mailprocessors of every domain (FidoNet compatible or not) if they
  66.    regard the address as case-sensitive or not.
  67.  
  68.    The FORMAT of <dest_address> is :
  69.  
  70.    <Address>[@<Domain>]
  71.  
  72.    Where <Address> is the valid username/address in the network <Domain>,
  73.    and <Domain> cannot have any '@' of '/'-characters in it, while
  74.    <Address> can. The reason why '/' characters are not allowed in the
  75.    <Domain>-field, is because they are necessary to recognize a
  76.    FidoNet-style address, since <Domain> is optional for messages that
  77.    won't be crossing domain- borders. (*)
  78.    
  79.    In other words:  The domain is always the string behind the last @ sign
  80.    in the <dest_address> field, except when domain would contain a
  81.    '/'-character. In that case, <Domain> is the default domain, and
  82.    <Address> is the complete string behind the DEST-kludge.
  83.  
  84.    Concerning FidoNet-compatible addresses, there are some extra rules,
  85.    since FidoNet is one of these rare networks that haven't got the
  86.    username in the address.
  87.  
  88.    A valid FidoNet <Address> is made up like this:
  89.  
  90.    <Username>@<Fido_Address>
  91.  
  92.    Where <Username>@ is mandatory and <Fido_Address> is a valid fidonet
  93.    address. The FidoNet-address must contain at least the zone:net/node
  94.    number. Point number is optional.
  95.  
  96.    Eg.: ^ADEST Wim Van Sebroeck@2:292/862.0@FidoNet.Org
  97.  
  98.    will generate an outbound message for user 'Wim Van Sebroeck' at
  99.    Fido-node 2:292/862.0 within FidoNet. The domain name for FidoNet is
  100.    'FidoNet.Org', and *not* just Fido, or FidoNet or whatever. This is not
  101.    a waste of space, since the domain name can be omitted when the message
  102.    remains in the default network. Only for messages crossing domain
  103.    borders, the domain name is necessary. We opted for the '.org' and
  104.    '.ftn' suffixes, in order to make interfacing to InterNet easier.
  105.    
  106.    Some more addressing-examples:
  107.    
  108.          ^ADEST Jan Spooren@2:292/852.0@Fidonet.Org
  109.          ^ADEST 292/862-cosysops@2:292/850
  110.          ^ADEST TE880714%BANUFS11@BITNET
  111.          ^ADEST Jack@OS/2.dev.itnet@itnet
  112.          ^ADEST m2xenix!uunet!BANUFS11.BITNET!TE880714@uucp
  113.    
  114.    The first example should be clear, since it will be the most frequently
  115.    used addressing-style.
  116.    The 4th example shows the kludge for a message to the address
  117.    'Jack@OS/2.dev.itnet', within domain 'itnet'. There is no problem
  118.    whatsoever with the '/' character, because it is part of the <Address>,
  119.    and not of the <Domain>.
  120.    In the last example, the message has to be sent to the uucp-gateway,
  121.    wich will send it on within the internet-network, with the
  122.    destination-address: 'm2xenix!uunet!BANUFS.11BITNET!TE880714'
  123.  
  124.    Also this is a valid address:
  125.  
  126.    ^ADEST Wim Van Sebroeck@2:292/862.0@FidoNet.Org@SIGnet.ftn
  127.  
  128.    The message will be sent to 2:292/862.0@FidoNet.Org, within SIGnet.ftn.
  129.    SIGnet will then send the message back to 2:292/862.0 in FidoNet.
  130.    The message will cross the domain-borders twice. Apart from the fact
  131.    that it may seem an annoying practice, technically the address is 100%
  132.    OK.
  133.       
  134.    Information in the DEST-kludge will always override information in the
  135.    FTS-0001 message header.
  136.  
  137.  
  138.  
  139.    FOOTNOTE:
  140.    
  141.    (*)
  142.  
  143.    For a proper understanding of this '/'-restriction, let's illustrate
  144.    this by means of an example. If we send a message with a kludge like
  145.    this:
  146.  
  147.    ^ADEST Wim Van Sebroeck@2:292/862
  148.  
  149.    Then the mailprocessor could wrongly interpret the <dest_address>:
  150.    It could decide the <address> to be 'Wim Van Sebroeck' in <domain>
  151.    '2:292/862'. But with the '/'-restriction it is now clear that the
  152.    address is 'Wim Van Sebroeck@2:292/862' in the default domain.
  153.  
  154.    
  155. 2) The ^AORIG kludge: this kludge contains the origin address.
  156.    <orig_address> has the same restrictions as the <dest_address>.
  157.  
  158.    For example: ^AORIG Wim Van Sebroeck@2:292/862.0@Fidonet.Org
  159.             or: ^AORIG Infomag.Dev@ITNet
  160.  
  161.  
  162. 3) The ^AROUTE kludge: this is needed to point to the gateway address, when
  163.    sending a message to another domain. Since not all gateways are listed
  164.    in the nodelist and because possibly not all intermediate systems are
  165.    aware of a particular domain-name, it is necessary to add the address of
  166.    the gateway.
  167.    The gateway is a system within the default domain, that can send the
  168.    message to the desired domain. The kludge can also be used, however, to
  169.    point to a zonegate between different zones in one domain. In any case,
  170.    for every domain-border that will be crossed, there needs to be one
  171.    ROUTE-kludge to indicate the gateway. It should be obvious, that a
  172.    FidoNet-address in a ROUTE-kludge never carries a username.
  173.    
  174.    The ROUTE-kludge always overrides the DEST-kludge. A system receiving a
  175.    message should ALWAYS send the message to the address specified by the
  176.    ROUTE-kludge, and NOT to the destination address. In other words, the
  177.    ROUTE-kludge is not to be interpreted as a hint to a possible gateway,
  178.    but must be regarded as a new destination address, and the message will
  179.    always have to reach the gateway. The gateway will then change the
  180.    ^AROUTE to a ^AROUTD kludge, in order to indicate that the gateway
  181.    received the message, and to see to it that the message won't travel
  182.    back to the gateway. This absolute priority of the ROUTE-kludge above
  183.    the DEST-kludge is necessary, since otherwise messages could be bouncing
  184.    between two nodes that both prefer different gateways to send the
  185.    message to.
  186.    The ROUTE-kludge also has nothing to do with the actual routing itself.
  187.    The ROUTE-kludge only defines an intermediate address that has to be
  188.    reached before the message reaches its final destination. How the
  189.    message gets to this intermediate address doesn't matter: it may be
  190.    direct or it may be routed through other systems. Remember that FidoNet
  191.    is an amateur network, with each system paying its own phone bills!
  192.  
  193.    For example: ^AORIG Wim Van Sebroeck@2:292/862.0@Fidonet.Org
  194.                 ^AROUTE 1:105/42.0@Fidonet.Org
  195.                 ^ADEST m2xenix!uunet!BANUFS11.BITNET!TE880714@uucp
  196.  
  197.  
  198. C. Advantages and Disadvantages :
  199. ---------------------------------
  200. a) Advantages:
  201.      - The main advantage is that one only needs two kludges to specify the
  202.        origin and the destination address. (And that these kludges are
  203.        always in a message).
  204.      - The system is also very flexible because any address is possible.
  205.      - Utilities must not be updated when a new address-dimension is created.
  206.      - Inter-domain and inter-network messages are finally possible.
  207.      - No limits are placed on both username and address-field length.
  208.      - Perfect compatibility is ensured with future message and packet 
  209.        formats that will override FTS-0001.
  210.  
  211. b) Disadvantages:
  212.      - Please be so kind to write them to us. We can't figure what they
  213.        could be?
  214.  
  215.  
  216. D. Implementation Notes :
  217. --------------------------
  218.  
  219. D.1. Processing an outgoing message.
  220.  
  221. .-----+----------+-------------------------+-------------------------+-----.
  222. |State| State    | Predicate(s)            | Action(s)               | Next|
  223. |  #  | Name     |                         |                         | St  |
  224. |-----+----------+-------------------------+-------------------------+-----|
  225. | O1  | MsgFound | Find DEST/ROUTE         | 1 Found fsc-58 kludge   | O2  |
  226. |     |          | kludges in message      | 2 Fsc-58 kludge not fnd | S8  |
  227. |     |          |                         | 3 Error occured         | exit|
  228. |     |          |                         | 4 Dest is 1 of our AKAs | exit|
  229. |-----+----------+-------------------------+-------------------------+-----|
  230. | O2  | ReadKldg |                         | Take only 1st ROUTE and | O3  |
  231. |     |          |                         | 1st DEST-kludge         |     |
  232. |-----+----------+-------------------------+-------------------------+-----|
  233. | O3  | ChkROUTE | Is there a ROUTE kludge | 1 Route kludge found    | O4  |
  234. |     |          |                         | 2 No route kludge       | O10 |
  235. |-----+----------+-------------------------+-------------------------+-----|
  236. | O4  | WeRoute? | Is ROUTE one of our     | 1 Yes                   | O5  |
  237. |     |          | AKA's                   | 2 No                    | O9  |
  238. |-----+----------+-------------------------+-------------------------+-----|
  239. | O5  | DsblROUT |                         | Change ROUTE into ROUTD | O6  |
  240. |     |          |                         | and strip 'TOPT' and    |     |
  241. |     |          |                         | 'INTL'-kludges to our   |     |
  242. |     |          |                         | system.                 |     |
  243. |-----+----------+-------------------------+-------------------------+-----|
  244. | O6  | WeGate?  | Are we a gateway to     | 1 Yes                   | O7  |
  245. |     |          | another domain?         | 2 No                    | O2  |
  246. |-----+----------+-------------------------+-------------------------+-----|
  247. | O7  | Needgate | Get next ROUTE/DEST-kldg| 1 Yes                   | O8  |
  248. |     |          | Is it another domain?   | 2 No                    | O3  |
  249. |-----+----------+-------------------------+-------------------------+-----|
  250. | O8  | Gateway  |                         | Do gatewaying-stuff     | exit|
  251. |     |          |                         | Don't forget to strip   |     |
  252. |     |          |                         | @<domain> from the      |     |
  253. |     |          |                         | <dest_address>          |     |
  254. |-----+----------+-------------------------+-------------------------+-----|
  255. | O9  | SndROUTE |                         | SendMsg to ROUTE        | S1  |
  256. |     |          |                         | (Temp. Dest = ROUTE)    |     |
  257. |-----+----------+-------------------------+-------------------------+-----|
  258. | O10 | SndDEST  |                         | SendMsg to DEST         | S1  |
  259. |     |          |                         | (Temp. Dest = DEST)     |     |
  260. `-----+----------+-------------------------+-------------------------+-----'
  261.  
  262.  
  263. D.2. Sending of an outgoing message
  264.  
  265. SendMsg(Temporary_destination)
  266.  
  267. .-----+----------+-------------------------+-------------------------+-----.
  268. |State| State    | Predicate(s)            | Action(s)               | Next|
  269. |  #  | Name     |                         |                         | St  |
  270. |-----+----------+-------------------------+-------------------------+-----|
  271. | S1  | Looktabl |                         | Find node to route to   | S2  |
  272. |     |          |                         | according to own routng |     |
  273. |     |          |                         | scheme and msg-attribs. |     |
  274. |-----+----------+-------------------------+-------------------------+-----|
  275. | S2  | IsFsc58  | Lookup in table if node | 1 No, not fsc-58 compl. | S3  |
  276. |     |          | is fsc-58 compliant     | 2 YES! Fsc-58 compliant | S8  |
  277. |-----+----------+-------------------------+-------------------------+-----|
  278. | S3  | FMPT     | Has ORIG-kludge point#  | 1 No                    | S4  |
  279. |     |          |                         | 2 Yes: Insert FMPT-kldg |     |
  280. |     |          |                         |   if not already present|     |
  281. |-----+----------+-------------------------+-------------------------+-----|
  282. | S4  | TOPT     | Contains                | 1 No                    | S5  |
  283. |     |          | temporary_destination   | 2 Yes: Insert TOPT-kldg |     |
  284. |     |          | a point-address ?       |   if not already present|     |
  285. |-----+----------+-------------------------+-------------------------+-----|
  286. | S5  | INTL     | Compare ORIG and        | 1 Zones equal           | S6  |
  287. |     |          | temporary_destination   | 2 Not eq. : Make INTL-k |     |
  288. |     |          |                         |   if not already present|     |
  289. |-----+----------+-------------------------+-------------------------+-----|
  290. | S6  | DOMAIN   | Compare ORIG and        | 1 Domains equal         | S7  |
  291. |     |          | temporary_destination   | 2 Not eq. : Domain-kldg |     |
  292. |     |          |                         |   if not already present|     |
  293. |-----+----------+-------------------------+-------------------------+-----|
  294. | S7  | Usernames|                         | Fill in FTS-1 dest and  | S8  |
  295. |     |          |                         | orig usernames, accord. |     |
  296. |     |          |                         | to ORIG and DEST except |     |
  297. |     |          |                         | when ORIG/D names blank |     |
  298. |-----+----------+-------------------------+-------------------------+-----|
  299. | S8  | XportMsg |                         | Export message          | Exit|
  300. `-----+----------+-------------------------+-------------------------+-----'
  301.  
  302.  
  303. D.3. Processing an incoming message:
  304.  
  305. .-----+----------+-------------------------+-------------------------+-----.
  306. | I1  | ChkKldg  | Find DEST/ROUTE/ORIG    | If found: store kludges | I2  |
  307. |     |          | kludges in message      |                         |     |
  308. |-----+----------+-------------------------+-------------------------+-----|
  309. | I2  | ChkFSC58 | Are DEST/ROUTE/ORIG     | 1 Yes, fsc-58 compliant | I3  |
  310. |     |          | Kludges available?      | 2 No, not fsc-58 compl. | I4  |   
  311. |-----+----------+-------------------------+-------------------------+-----|
  312. | I3  | ChkTable | Is originator of packet | If not in lookup-table  | I4  |
  313. |     |          | in lookup-table? ^^^^^^ | and should be, then     |     |   
  314. |     |          |      ( SEE SECTION E !) | add node to the table   |     |   
  315. |-----+----------+-------------------------+-------------------------+-----|
  316. | I4  | ChkDEST  | Is message to us?       | 1 Yes: store message    | exit|
  317. |     |          | (Are we DEST?)          | 2 No                    | I5  |
  318. |-----+----------+-------------------------+-------------------------+-----|
  319. | I5  | KeepTrans| Do we keep a copy of in-| 1 Yes: Store msg and -->| O1  |
  320. |     |          | transit mail ?  :-(     | 2 No:                   | O1  | 
  321. `-----+----------+-------------------------+-------------------------+-----'
  322.  
  323.  
  324.  
  325. E. Discussion of the Implementation Notes.
  326. ------------------------------------------
  327.  
  328. * O5, "DsblROUT" :
  329.  
  330.   It is clear that when a message travels through an intermediate system 
  331.   which is mentioned in a ROUTE-kludge, this ROUTE-kludge will have to be 
  332.   removed, because the message did arrive at this system.  Instead of just 
  333.   deleting the whole kludge-line, the kludge will be changed in ROUTD.
  334.   This is a much easier and faster process for a mailprocessor and it 
  335.   enables the recipient of the message to have some information about the 
  336.   route the message took.
  337.  
  338.   Because there is no FTS-0001 equivalent to the route-kludge, a system that 
  339.   is in a route-kludge needs to be FSC-0058 compliant.  The intermediate 
  340.   systems to this ROUTE-system need not to be FSC-0058 compliant: Our 
  341.   implementation notes assume a list of fsc-0058 compliant nodes (the 
  342.   'lookup table'), that is continuously updated, when messages arrive from 
  343.   fsc-0058 systems.  When a message is to be send on to a non-fsc-0058 
  344.   system, the message will be converted to the old FTS-0001 format, 
  345.   including FMPT-, TOPT- and INTL-kludges.  The destination-address in this 
  346.   (converted) message will then be the address of the first ROUTE-kludge.  
  347.  
  348.   There is one tricky point:  When such a message arrives at this ROUTE-
  349.   system, the message can have TOPT (if the system is a pointsystem) and 
  350.   INTL kludges in the messagebody, due to the conversion to the FTS-0001 
  351.   format.  The ROUTE-system's mailprocessor will have to find these and 
  352.   strip them from the message.
  353.  
  354. * S3 -> S7 :
  355.  
  356.   These stages perform the conversion to FTS-0001 format, in case the next 
  357.   receiving system will be non-fsc-0058 compliant.
  358.  
  359. * I3, "ChkTable" :
  360.  
  361.   Care must be exercized:  If we find FTS-0058 information in a message 
  362.   we don't know if the last system, or any of the previous systems the 
  363.   message passed is fsc-0058 compliant.  We can only know for sure when the 
  364.   message was sent directly to us.  That is (in FidoNet packet type 2) when 
  365.   the packet-orig address is the same as the message orig-address, or when 
  366.   the packet-orig address is the same as the last routd-kludge address.
  367.  
  368.   We are aware of the fact that the lookup-table won't be filled fast this 
  369.   way.  But we don't want that:  We only have to know if our 'surrounding' 
  370.   nodes, i.e., the nodes with which we have frequent connections, support 
  371.   fsc-0058.  
  372.   We also want to know if gateway systems are fsc-0058 compliant, because we 
  373.   have to put them in a ROUTE-kludge.  But these should be just a few 
  374.   systems and the fact of their fsc-0058 compliance will be known easily.  
  375.   They can then be added manually.
  376.  
  377.   We do not even dare to suggest the use of a nodelist-flag, that could 
  378.   simplify this whole system of investigating the fsc-0058 compliance, in 
  379.   order to downgrade to the FTS-0001 level for non-compliant systems.
  380.  
  381.  
  382.   
  383. F. Questions :
  384. ---------------
  385. Questions can always be sent to:
  386.  
  387.     Jan Spooren             2:292/852.0@Fidonet.Org
  388.     Wim Van Sebroeck        2:292/862.0@Fidonet.Org
  389.  
  390.    
  391.    
  392.                       --- End Of Proposal ---
  393.